home *** CD-ROM | disk | FTP | other *** search
- Path: news.rhrz.uni-bonn.de!zeus!fasten
- From: fasten@zeus.informatik.uni-bonn.de (Bernhard Fastenrath)
- Newsgroups: comp.sys.amiga.misc
- Subject: Re: OS features
- Date: 31 Jan 1996 19:05:49 GMT
- Organization: Universit"at Bonn, Informatik Abt. II, R"omerstr. 164, 53117 Bonn
- Message-ID: <4eoeid$k6f@news.rhrz.uni-bonn.de>
- References: <4e657d$2db@news.rhrz.uni-bonn.de> <4950.6603T1192T1630@teclink.net>
- NNTP-Posting-Host: zeus.informatik.uni-bonn.de
- X-Newsreader: TIN [version 1.2 PL2]
-
- rad (rad@teclink.net) wrote:
-
- : >Michael van Elst (mlelstv@serpens.rhein.de) wrote:
- : >: wayne@focus-systems.on.ca (Wayne Fisher) writes:
-
- : ><...>
- : >: > - new programs' code and data would be protected from access by
- : >: > another
- : >: > process unless explicitly allowed by the program.
-
- : >: Kills close to all system functions. You had to write a completely new
- : >: AmigaOS.
-
- : >Maybe not. Let's say (as you suggested earlier) that some subsystems
- : >(e.g. Intuition) have the permission to read and write any memory region.
- : >Intuition functions would have to check if the pointers received from
- : >process A point into A's memory and, of course, if they are consistent
- : >and don't corrupt Intuition's internal data when used (That's a good piece
- : >of work for the programmers and for Intuition at runtime but I guess it's
- : >possible).
- : >Programs which want to browse internal data structures of Intuition are
- : >either given permission or fail.
-
- : First intuition is currently called within all the tasks which open it. In
- : order to allow intuition to access any memory region all processes with
- : intuition open (practically all processes) must be able to access any memory
- : region, or intuition must be changed drastically to run out of a separate
- : process(es) in which case you add the large overhead of a context switch
- : for each intuition function call. The same goes for many other libraries too.
-
- A context switch for every intuition call is probably no a good idea (Even though
- it sounds like a microkernel approach).
- A unix system call switches to kernel mode and back to user mode by means of
- an interrupt without a context switch, this sounds more like what I had in mind.
- It should be possible to make a low-overhead switch to another mode when a
- system library that requires special permissions is called.
-
- : ><...>
- : >: >"much more"? I don't think a few percentages is "much more".
-
- : >: You forget that memory protection is nothing if you cannot protect
- : >: the system from invalid parameters to system functions. Most system
- : >: functions however use shared data structures.
-
- : >How about this: Write access to a data structure shared between a process
- : >and Intutition marks the data structure as dirty and Intuition has to
- : >perform consistency checks again before using it.
-
- : Are you willing to sacrifice the speed to do these checks on almost every
- : intiution function call?
-
- Make it optional (sys:prefs/kernel).
-
- : >: The whole concept of device drivers had to be changed.
- : >: BOOPSI is dead.
- : >: System hooks are dead.
-
- : >Device drivers would have to be a subsystem with the license to kill
- : >(read/write everything). System hooks would be restricted to programs
- : >which were given special permission.
-
- : The problems here are that you are punching wholes in your memory protection
- : for almost all software out there, and requiring major OS changes... This is
- : what people have been trying to point out for years.
-
- I know :-(
-
- : >: >It
- : >: >just means that you can't pass pointers between processes and the
- : >: >machine becomes more stable.
-
- : >: Unfortunately most parameters are passed by pointers. You do have
- : >: to change everything.
-
- : >Old programs could use one address space and pass pointers as much as
- : >they want to. Maybe if A calls PutMsg() it gives the receiving process B
- : >the permission to read/write its memory. New programs could
- : >also use PutMsg() but they'd allocate the message from a special pool
- : >and the other task receives only read/write permission for this pool.
- : >The private memory of new programs wouldn't have to be in the global
- : >address space.
- : >Another difference between old and new programs could be that the memory
- : >of old programs must not be swapped while new programs can decide for
- : >each of their pools if it has MEMF_SWAP set or not.
-
- : Part of the problems with this is current software usually does not allocate
- : memory for messages separately from everything else leaving the OS guessing at
- : the size of the messages. Further messages usually contain pointers to other
- : blocks of memory outside of the message which may need to be both read and
- : written by the receiver. Therefor to support current programs the sender's
- : entire memory space must be made available to the receiver and further must be
- : mapped into the exact same address space for the receiver as the sender.
- It wouldn't have to be mapped. My idea was that old programs automatically get
- memory addresses which are valid in one global address space.
-
- : Before you know it every process has access to almost every other processes
- : memory.
- That's a problem for old software, yes. A new dos.library/filesystem handler
- would already close the biggest hole, I guess.
-
- : The only workable approach I see is to provide enforcer style protection for
- : old programs (breaks only a few poorly written/tested programs). All tasks
- : can read/write all other tasks; however, access of free or non-existant memory
- : will kill a large percentage of "bad" programs.
- If there ever will be a sys:prefs/kernel they can call this
- "Memory Protection: Medium" :-)
-
- : It may be possible (with great effort) to add new modes of protected memory
- : for new programs/libraries/devices/resources. The problems with this are of
- : course major changes required of the OS, the possible requirement that new
- : programs only open new libraries/datatypes/devices/resources, the possible
- : requirement that new libraries/datatypes/devices/resources are never called by
- : old programs... just to name a few.
-
- --
-
- _|_|_|_|_|_|_|_|_|_|_|_|_|_|_///_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
- _| Bernhard Fastenrath /// http://titan.cs.bonn.edu/~fasten/ : _|
- _| fasten@cs.bonn.edu \\\/// - XWorkbench 0.2 (Amiga Workbench for X11) _|
- _| fasten@shw.com \XX/ - Ext2 filesystem 0.5b for AmigaDOS, 0.3 _|
- _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
-
- Hi, I'm not a signature virus. Why don't you just copy me into your signature?
-